IP (Internet Protocol) Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
The Universal Mobile Telecommunications System (UMTS) is a third generation wireless system designed to provide higher data rates and enhanced services to users. The UMTS architecture includes a subsystem known as the IP Multimedia Subsystem (IMS) for supporting traditional telephony as well as new IP multimedia services. IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet. 3GPP IMS Release 8 provides support for Long Term Evolution (LTE), System Architecture Evolution (SAE).
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. The 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.
By way of example, FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS (General Packet Radio Services, Packet Switched) access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end users in an IMS system, and may be connected either as end-points over the 3GPP (3rd Generation Partnership Project) defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment (or indeed for the purpose of any SIP method, session or non-session related). The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's Subscriber Profile.
The 3GPP specification TS 24.147 entitled “Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem” specifies (in chapter 5.3.1.5.4) how an IMS user can initiate a conference call by sending a SIP INVITE to the IMS network, with the INVITE identifying the peer conference participants by way of a URI list. Each entry in the list will typically be a SIP or Tel URI of another IMS user. RFC 5368 further specifies how the SIP REFER method can be used to add participants to an established conference.
FIG. 2 illustrates signalling associated with establishing a 3-way conference call (involving an originating participant A and invited participants B and C) according to TS 24.147. In this example, the initiating INVITE includes a URI list containing the SIP URIs of B and C. The signalling flow transits Multimedia Telephony Application Servers (MTASs) associated with each of the IMS users A, B and C. In addition, the signalling transits a MTAS conference server which acts both as a conference factory and as a focus. [The conference factory and focus may be allocated on the originating or terminating side AS. Both of these scenarios utilise a Public Service Identity (PSI as specified in TS 24.147.] A Mixer Media Resource Function Controller (MRFC) is notified of the inclusion of the participants in the conference and is responsible for ordering mixing media in the user plane using a Media Resource Function Processor (MRFP).
OCB (Outgoing Communication Barring) is described in the 3GPP TS 24.611 specification and is a service that can be implemented by or on behalf of IMS users to prohibit outgoing calls to particular users or to classes of users. By way of example, OCB may be used to prevent a user calling abroad. In the case of a normal, two party peer-to-peer call, if an OCB service implemented on behalf of the call initiator determines that the call should be blocked, the OCB AS will send a SIP 603 Decline response to the call initiator. Additionally, before terminating the communication the OCB AS can provide an announcement to the call initiator. The procedure to invoke an announcement is described within 3GPP TS 24.628
In chapter 4.6.6, TS 24.611 deals with the application of OCB to conference calls, stating in particular that:                “If the conference creator activated the OCB service then, the AS providing the CB service shall remove the URI that is barred by the conference creator's Outgoing Communication Barring (OCB) rules from the list of URIs in the “recipient-list” body of INVITE request.”Following the removal of the barred URI(s) from the INVITE, the request is forwarded to the conference server.        
As it stands, the current OCB proposals may result in peer users being excluded from the invitation list for a conference call without the conference initiator being given any indication either that those peer users have been excluded or the reason for their exclusion. The AS providing the OCB service for the originating user is not required to send any information backwards to the conference creator, and in particular will not return a 603 Decline message. Whilst it is possible for the conference creator to subscribe for conference events by sending a SUBSCRIBE to the conference focus, see TS 24.147/RFC 4575, it will be appreciated that the conference server will have no knowledge of the removed URIs as this removal is carried out by the OCB AS in advance of the INVITE being received by the conference server.